1. Field of the Invention
The present invention relates to an apparatus and method for communicating between a master device and an asynchronous slave device via an interface. The asynchronous slave device is a slave device whose clock signal is asynchronous to the clock signal used by the master device.
2. Description of the Prior Art
There are many situations where the number of signals available for communication between a master device and a slave device is limited, and in such situations each multi-bit item of information has to be transmitted in at least a partially serial manner. Often the information is arranged into packets for transfer between the master device and the slave device, each packet comprising a plurality of bits. The master device initiates transactions, each transaction comprising a plurality of transfers including a master transfer to transmit a packet from the master device to the slave device and a slave transfer to transmit a packet from the slave device to the master device
In such systems, the interface is often referred to as a serial interface since each multi-bit item of information is transmitted in at least a partially serial manner. Such a serial interface is also often referred to as a reduced pin count interface since there is not a separate pin provided for each bit of the multi-bit item of information to be transmitted. For example, if each item of information is 32-bits in size, such a serial interface will typically have significantly less than 32 pins, and indeed in some situations there will only be a single pin, such an interface being referred to as a single wire interface.
There are many situations where such serial interfaces are used, one example being in situations where the master device and the slave device reside on different chips, particularly in low cost devices where reduction in size of the interface is more important than overall performance. Such serial interfaces are also used to support ancillary functions such as debugging, where the cost and size of a parallel interface is typically prohibitive.
In situations where the clock signal of the slave device is asynchronous to the clock signal of the master device, this gives rise to an issue of how to synchronise the transfer of packets over the serial interface between the master device and the slave device. In some implementations, a separate pin can be provided for transmission of a clock signal between the master and slave devices. For example, it is known to provide a two wire debug interface, where one wire is used for the transfer of packets between the master device and the slave device, and the other wire is used for the transmission of a clock signal.
However, there is an increasing desire to reduce the pin count at the periphery of devices, and hence having to provide a separate wire for the transmission of the clock signal is undesirable.
A number of known solutions exist which avoid the need for a separate pin for transmission of a clock signal over a serial interface. One known technique is a “source synchronous” technique, as used for example for Ethernet, PCIe and SATA communication. In accordance with this technique, the transmitting side (which will be the master device for some transfers, and the slave device for other transfers) always uses its own clock and encodes the data of the packet in a way that guarantees regular data edges (for example by using Manchester encoding, 8B/10B). The receiving side then contains clock recovery logic that can reconstruct a replica of the original clock from these regular data edges, which is then used to sample the data provided in the packets. This can be done using phase locked loop (PLL) circuits or the like, which are large and expensive and often require an accurate reference clock. Another approach is to oversample the incoming data, but this requires a high speed clock on the receiving side which may not be available in all situations, and limits the maximum link speed over the interface.
Another known approach is a “timed” approach such as used in Universal Asynchronous Receive Transmit (UART) interfaces and IR remote controls. In accordance with such techniques, the bit periods have a fixed and predetermined width. The data can be encoded in number of ways, for example a high voltage may indicate a logic one value, whilst a low voltage indicates a logic zero value, with all bits having the same width. Alternatively, the signal over the interface may default to a low voltage level, and a logic one value is represented by a pulse of a predetermined width, with a logic zero value being represented by a pulse of a different, but also predetermined, width. However, because these types of protocol rely on fixed timings, they typically require a high speed clock of known frequency. They are also usually oversampled, which can limit the maximum link speed. Various examples of systems employing the “timed” approach include the Intersil system described in Intersil, ISL6296, Flexihash™ For Battery Authentication, Mar. 21, 2008, the “1-Wire” device communications system bus developed by Dallas Semiconductor Corp. and described in Wikipedia, 1-Wire, and the Single Wire Protocol (SWP) described in ETSI TS 102 613 v7.7.0 (2009-10), Technical Specification, “Smart Cards; UICC—Contactless Front-end (CLF) Interface; Part 1: Physical and data link layer characteristics (Release 7).
Another known approach is a “master synchronous” approach where all transmitted data is synchronous to the master device, including data transmitted by the slave device. To accomplish this, the protocol is designed such that the slave is given regular edges from the master device which it can use to infer what the master clock frequency is. A replica of the master clock is then created by the slave device and used to sample the incoming data, or to send response data back to the master device. Although the overall approach of creating a replica of the clock is similar to the source synchronous system mentioned above, a key difference here is that the complexity is biased to the slave side, thus enabling the master device to treat the interface as if it were synchronous to it. However, such an approach requires the slave device to have some form of PLL circuit and a high speed reference clock, or to limit the link speed and make use of oversampling techniques. An example of such a master synchronous system is described in the Microchip UNI/O specification, Microchip, 1K-16K UNI/O® Serial EEPROM Family Data Sheet, Microchip Technology, Inc., 2010. Some other master synchronous approaches are described in US2011/170645A, US2008/151792A and JP4326826A.
Whilst the master synchronous approach has a benefit over the source synchronous approach, in that the complexity required for synchronising the packets is limited to one side of the link, namely the slave side, there are many situations where it is not practical to support such complexity within the slave device. For example, in implementations such as debug interfaces, the available resources within the slave device/debug target are restricted (for example a high speed reference clock is often not available, and there is insufficient die area available to provide complex logic or PLLs).
Conceptually, a slave synchronous approach (effectively the opposite of the master synchronous approach described above) would appear to be an attractive technique for overcoming the complexity limitations within the slave device. In accordance with such an approach, the slave device would treat the interface as if it were synchronous to its clock, and the master device would then create a replica of the slave clock which it uses to sample incoming data from the slave device and to transmit data to the slave device. However a problem that arises is that each transaction (involving at least one transfer from the master device to the slave device, and at least one transfer from the slave device to the master device) is initiated by the master device, and since the transaction is initiated by the master device the master device needs to have sufficient information about the slave clock at the time the transaction is initiated. Hence, a mechanism needs to be provided to enable the master device to get such information about the slave clock, and that mechanism cannot itself require a transaction to be issued that relies on the replica clock maintained by the master being an accurate representation of the slave's clock.
One way to seek to provide such a slave synchronous technique is described in US 2005/0091428. In accordance with the technique described in that patent application, prior to every data transaction the master unit sends a start signal to the slave unit, and in response to that start signal the slave unit sends to the master unit a synchronisation field that is a data train (pulse signal) indicative of the slave unit's transfer clock. The master unit then uses this sample to send command data to the slave unit in accordance with the transfer clock as indicated by the synchronisation field sent from the slave unit. In response to the command data, the slave unit then sends to the master unit response data in accordance with the transfer clock indicated by the synchronisation field. One problem with this approach is that it is necessary to send a sample of the slave clock prior to every transaction. As a result, this sample has to be kept relatively short in order to reduce the overhead of the described protocol. However, as a result of keeping the sample relatively short, this adversely affects the accuracy with which the master device can create a replica of the slave unit's clock, and even when the sample is kept relatively short it still represents an overhead associated with every transaction.
Accordingly, it would be desirable to provide an improved mechanism for communicating over an interface between a master device and an asynchronous slave device, which enables the complexity of the slave device to be reduced, whilst still allowing relatively high data rates to be achieved when transmitting data over the interface.